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Abstract 


Systems  engineering  is  a  key  discipline  for  the  development,  deployment,  and 
sustainment  of  military  systems.  The  wide  variety  of  product  types  and  tendency  to 
leverage  emerging  technologies  require  that  disciplined  technical  planning  and  the 
management  processes  be  used  by  engineers  and  program  managers  in  all  phases  of  a 
product’s  life  cycle.  This  chapter  will  explore  some  fundamentals  for  a  variety  of  topics 
in  military  systems  engineering  and  acquisition.  Focused  on  systems  engineering,  a 
couple  of  Army  vehicle  applications  are  also  presented. 
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Introduction 


Systems  engineering  is  commonly  defined  as  (a)  disciplined  technical  planning  and 
management  or  (b)  the  process  by  which  a  stated  user  desire  is  transformed  into  a 
tangible  product  that  is  optimized  in  terms  of  affordable  operational  effectiveness. 
Systems  engineering  is  a  key  discipline  for  the  development,  deployment,  and  the 
sustainment  of  military  systems.  The  wide  variety  of  Army  product  types  and  the 
tendency  to  leverage  emerging  technologies  require  that  disciplined  technical  planning 
and  management  processes  be  used  by  engineers  and  program  managers  in  all  the  phases 
of  a  product’s  life  cycle. 

Setting  the  Context 

The  Defense  Acquisition  System,  as  defined  in  the  Department  of  Defense  (DoD) 
Directive  5000.01  and  DoD  Instruction  5000.02,  provides  a  high  level  framework  within 
which  the  military’s  official  Programs  of  Record  must  be  used  to  develop,  field,  and 
sustain  their  systems.  Acquisition  Programs  of  Record  are  directed,  funded  efforts  that 
provide  new,  improved,  or  continuing  materiel,  weapon  or  information  system,  or  service 
capability  in  response  to  an  approved  need.  The  Defense  Acquisition  System  is  most 
commonly  communicated  through  the  use  of  the  “wall  chart”  (Figure  1)  which  depicts 
the  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management 
System.  This  “wall  chart”  is  published  by  the  Defense  Acquisition  University  (DAU)  and 
can  be  downloaded  free  of  cost  from  https://acc.dau.mil/ifc/download  pdf.htm  . 
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Figure  1:  The  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle 
Management  System,  also  commonly  known  as  the  “Wall  Chart” 
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The  “wall  chart”  for  systems  acquisition  and  engineering  in  the  Department  of  Defense 
(DoD)  depicts  a  flowchart  occurring  through  a  series  of  rows  and  columns.  The  columns 
divide  a  given  system’s  lifecycle  into  the  following  major  phases:  Materiel  Solution 
Analysis,  Technology  Development,  Engineering  &  Manufacturing  Development, 
Production  &  Deployment,  and  Operations  &  Support.  Each  of  the  above  phases  are 
divided  by  decision  points.  There  are  three  major  rows  shown  on  the  chart.  The  Defense 
Acquisition  System  is  the  most  detailed  row  which  is  in  the  middle  of  the  chart.  In  the 
chart,  it  becomes  obvious  that  each  of  the  major  lifecycle  phases  contain  their  own 
tailored  “systems  vee”  that  defines  the  overall  phase- specific  systems  engineering  process 
to  be  followed.  Referring  back  to  the  second  definition  of  systems  engineering  provided 
in  the  section  titled  “Introduction”,  the  columns  in  the  “wall  chart”  depict  how  a  required 
operational  capability  is  transformed  from  a  stated  user  desire  to  an  affordable, 
operationally  effective,  tangible,  fielded  and  sustainable  product  or  capability. 

The  top  row  on  the  chart  depicts  the  Joint  Capabilities  Integration  and  Development 
System  (JCIDS).  The  JCIDS  is  the  process  by  which  validated  operational  requirements 
are  generated.  These  requirements  serve  as  the  official  “voice  of  the  customer”  that  must 
be  transformed  into  tangible  systems  by  the  acquisition  community.  As  part  of  the  JCIDS 
process,  a  Capability  Based  Analysis  (CBA)  is  periodically  conducted  to  identify 
weaknesses  or  gaps  in  the  military’s  existing  or  planned  capability,  or  to  identify 
opportunities  to  enhance  capability  based  on  developments  using  emerging  technology.  If 
the  CBA  results  in  required  new  capabilities  that  cannot  be  solved  through  changes  to 
force  training,  policy,  or  other  conventional  factors  then  an  Initial  Capabilities  Document 
(ICD)  is  developed  to  document  the  high  level  operational  requirements  for  a  new 
capability.  An  ICD  essentially  serves  as  the  first  and  highest  level  configuration  baseline 
for  a  yet  to  be  developed  system  or  a  series  of  systems.  During  the  Materiel  Solution 
Analysis  phase  of  the  lifecycle  management  framework,  a  Capabilities  Development 
Document  (CDD)  is  then  collaboratively  developed  between  the  requirements  generation 
and  the  acquisition  communities.  More  details  on  the  operational  requirements  are 
detailed  in  the  CDD  based  on  the  current  state  of  technology  and  a  variety  of  trade  off 
analyses  that  seek  to  balance  the  correct  degree  of  capability  which  is  focused  on 
maximizing  the  affordable  operational  effectiveness  of  a  system.  The  CDD  is  refined 
during  the  Technology  Development  phase  prior  to  Milestone  B.  At  Milestone  B,  the 
CDD  is  locked  and  serves  as  a  more  detailed  configuration  baseline  of  the  operational 
capability  to  be  delivered.  During  the  Engineering  &  Manufacturing  Development  phase 
of  a  program,  a  Capability  Production  Document  (CPD)  is  crafted  prior  to  Milestone  C.  A 
CPD  is  written  at  the  same  level  of  detail  as  the  CDD,  but  reflects  any  operational  trade¬ 
offs  or  changes  that  may  have  occurred  between  Milestones  B  and  C.  In  many  cases,  a 
program  may  progress  directly  to  Milestone  C  after  the  ICD  has  been  generated  if  the 
Material  Solution  Analysis  phase  may  have  suggested  that  integration  of  the  technology 
is  expected  to  be  low  risk  or  if  a  Commercial-Off-The-Shelf  (COTS)  system  exists  to 
meet  the  operational  requirements  with  minor  modification.  The  JCIDS  process  also 
includes  a  very  specific  approval  process  to  validate  requirements.  This  usually  includes 
oversight  by  leaders  from  the  joint  services  representing  the  Army,  Navy,  and  Air  Force 
to  enhance  the  joint  integration  of  systems. 
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The  lower  row  of  the  “wall  chart”  depicts  the  Planning,  Programming,  Budgeting  and 
Execution  (PPBE)  process.  This  is  the  process  by  which  funds  are  planned  for,  allocated, 
and  managed  at  a  high  level.  While  the  JCIDS  row  and  Defense  Acquisition  System  row 
are  synchronized  with  each  other  in  time  on  the  chart,  the  PPBE  row  is  independent  of 
the  other  two  rows  and  is  synchronized  with  the  biennial  calendar  followed  by  the 
government  branches.  In  practice,  executing  major  programs  that  take  many  years  to 
develop  and  field  can  be  challenging  considering  that  the  funding  is  being  provided  based 
on  the  biennial  PPBE  process  (in  which  priorities  may  shift  as  the  composition  of  the 
government  branches  change  and  their  respective  priorities  evolve  with  time).  Interaction 
between  the  PPBE  process,  the  JCIDS  process,  and  the  Defense  Acquisition  System  is 
shown  in  Figure  2. 


DoD  Decision 
Support  Systems 
Effective  Interaction 
is  Essential 


For  space  systems  see 
t-labor.al  Security  Space 
Acquisition  Policy  03-0  I 


Figure  2:  Interaction  of  the  Three  Decision  Support  Systems  Depicted  within  the 

“Wall  Chart” 


It  should  be  noted  that  while  the  Defense  Acquisition  System  defines  the  framework 
within  which  systems  that  are  intended  to  be  fielded  will  operate,  it  does  not  address  how 
Research  &  Development  (R&D)  activities  are  to  take  place.  The  defense  R&D 
community  uses  many  of  the  same  systems  engineering  framework  tools,  although  it  has 
more  freedom  for  how  each  individual  R&D  program  is  managed.  The  tools  described  in 
this  chapter  will  focus  on  systems  engineering  elements  used  in  both  acquisition  and 
R&D. 


Systems  Engineering  Relation  to  Program  Management 


There  are  a  number  of  similarities  between  the  disciplines  of  systems  engineering  and 
program  management,  depicted  in  the  Venn  diagram  (Figure  3).  Systems  engineering  can 
essentially  be  thought  to  represent  a  major  subset  of  program  management.  Program 
design,  risk  management,  work  breakdown  structures,  earned  value  management,  and 
schedule  management  through  the  use  of  integrated  master  plans  and  schedules  are  all 
aspects  that  ride  a  fine  line  between  systems  engineering  and  program  management. 
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-  Adapted  from  Kossiakoff  &  Sweet  (2003) 


Figure  3:  Interaction  between  Program  Management  and  Systems  Engineering  (1) 


Therefore,  it  is  paramount  that  an  understanding  of  systems  engineering  processes  and 
techniques  reside  not  only  with  the  engineers  supporting  acquisition  programs  and 
executing  R&D  programs,  but  also  with  the  system  acquisition  managers,  product 
managers  and  program  managers  who  lead  the  programs.  Many  individuals  in  the  DoD’s 
Program  Management  career  field  have  areas  of  background  and  expertise  in  contracting, 
logistics,  and  business  management.  Hence,  it  is  important  that  the  engineers  with 
backgrounds  in  systems  engineering  communicate  with  their  Program  Management 
career  field  counterparts  and  help  to  integrate  disciplined  technical  planning  and 
management  into  the  broader  community. 


Systems  Engineering  Focus  Areas  and  Skills 

The  purpose  of  good  systems  engineering  practice  should  be  to  enable  a  given  project’s 
team  to  early  on  answer  crucial  questions  such  as  the  following  during  the  planning 
phases  of  the  project: 

•  What  are  the  key  technical  reviews  that  will  be  used  to  establish  critical 
technical  baselines  such  as  locked  operational  level,  configurations  at  system  , 
sub-system,  and  product  levels  to  ensure  that  the  program  is  ready  for  the 
subsequent  activity? 

•  Who  will  have  control  over  the  different  levels  of  technical  baselines? 

•  What  is  the  Integrated  Product  Team  (IPT)  structure,  and  how  does  the  program 
ensure  that  it  takes  into  account  the  advice  of  subject-matter  experts  (SMEs)  in  all 
applicable  areas? 

•  What  processes  will  be  used  to  oversee  key  activities,  such  as  requirements 
management,  configuration  management,  risk  management,  obsolescence 
management  and  data  management? 
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•  What  are  the  highest  technical  risks,  and  how  will  the  program  act  to  mitigate 
them? 

•  How,  specifically,  will  the  program  manage  technology  transition  to  exploit 
opportunities? 

Systems  engineering’s  objective  is  to  answer  these  questions  early  in  the  acquisition 
process  so  that  they  can  be  answered,  agreed  upon,  and  understood  by  all  IPT  members 
prior  to  executing  a  program’s  subsequent  phase. 

Some  of  the  most  common  focus  areas  and/or  skills  desired  for  systems  engineers  in  a 
military  environment  are  as  follows: 

•  design  and  support  of  configuration  management  processes; 

•  design  of  technical  schedules,  design  and  conduct  of  technical  reviews; 

•  coordination  of  technology  assessments; 

•  composition  of  IPTs; 

•  market  research; 

•  requirements  development; 

•  requirements  management; 

•  requirements  decomposition  and  design  of  functionality; 

•  comparison  of  market  research  with  operational  and  performance  requirements; 

•  risk  analysis; 

•  development  of  mitigation  strategies  to  technical  risks; 

•  development  of  modeling  and  simulation  strategy; 

•  development  of  test  strategy; 

•  alignment/synchronization  of  technical  efforts; 

•  developing  and  performing  trade  studies; 

•  system  of  systems  (SoS)  engineering; 

•  contract  design  (integration  of  technical  risk  reduction  strategies  into  contracts); 

•  collection  and  analysis  of  field  data; 

•  integration  of  new  technologies  and  subsystems; 

•  interoperability  management; 

•  obsolescence  management; 

•  technical  baseline  management; 

•  electromagnetic  spectrum  management; 

•  compliance  with  legal  and  regulatory  requirements; 

•  lifecycle  product  data  management; 

•  technology  readiness  assessments; 

•  technical  management; 

•  communication  skills; 

•  concept  development; 

•  interface  management; 

•  capability  gap  analysis; 

•  design  of  architectures  (definition  of  relationships  at  different  levels); 

•  decision  analysis  and 
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optimization  of  design  considerations. 


Select  important  topics,  relating  to  the  focus  areas  stated  above,  are  discussed  in  more 
detail,  throughout  the  remainder  of  this  chapter. 

Requirements  Development 

It  is  important  to  draw  the  distinction  between  requirements  development  and 
requirements  management.  Requirements  development  is  the  process  of  investigating 
and  capturing  the  “voice  of  the  customer”  in  combination  with  the  “voice  of  the 
business”.  Requirements  management  is  the  process  of  ensuring  adequacy  and 
maintaining  the  integrity  between  the  different  levels  of  requirements. 

As  part  of  the  requirements  development  process  in  a  military  environment,  the  voice  of 
the  customer  primarily  is  captured  from  the  JCIDS  process,  described  earlier  in  this 
chapter.  The  requirements  derive  from  a  combination  of  different  factors,  such  as  the 
wants  and  needs  of  soldiers  operating  in  the  field,  maintainers  of  equipment,  training 
facilities,  strategic  combat  operations  planners,  and  more.  The  “voice  of  the  business”  is 
also  incorporated  into  the  JCIDS  process  and  takes  into  account  the  more  high  level 
strategic  direction  of  the  President,  the  strategic  vision  of  the  DoD  and  the  subordinate 
services,  and  more.  Legal  requirements,  such  as  environmental  and  safety  regulations,  as 
well  as  the  voice  of  the  taxpayer  are  also  considered. 

The  CBA  process  within  the  JCIDS  process  consists  of  several  sub-tasks.  A  functional 
area  analysis  is  first  conducted  where  the  baseline  existing  operational  capabilities  of  the 
armed  forces  are  reviewed.  A  functional  needs  analysis  is  then  conducted,  when  the 
required  operational  capabilities  for  a  given  mission  area  are  reviewed  based  on 
changing  threats  and  tactics  of  combat  and  logistics  operations.  A  functional  solutions 
analysis  is  then  conducted  where  the  differences  between  the  existing  and  the  required 
capabilities  are  each  analyzed  in  more  detail  to  identify  action  plans  for  how  to  bridge 
the  gaps  between  them.  Solutions  may  consist  of  changes  to  one  or  more  of  the  domains 
within  what  is  commonly  referred  to  as  Doctrine,  Organization,  Training,  Materiel, 
Leadership,  Personnel,  Facilities  (DOTMLPF).  If  a  recommended  change  to  the 
“materiel”  domain  of  DOTMLPF  results  from  the  CBA,  then  an  ICD  is  drafted  to 
establish  a  new  validated  operational  capability  requirement  to  be  fulfilled  and  thus 
initiate  a  new  development  effort  for  a  particular  system. 

On  validation  of  the  ICD,  a  more  detailed  operational  requirements  document  is  drafted, 
outlining  the  fundamental  requirements  of  the  new  capability.  A  draft  CDD  is  prepared 
before  a  program  enters  Milestone  A  (assuming  that  the  program  does  not  proceed 
directly  to  Milestone  B  or  C  based  on  assessed  lower  risk).  After  a  successful  Milestone 
A  decision,  the  Technology  Development  (TD)  Phase  of  a  program  is  conducted.  The 
purpose  of  the  TD  Phase  is  to  conduct  risk  mitigation  to  determine  whether  or  not  the 
requirements  listed  in  the  draft  CDD  are  achievable.  If  the  requirements  are  found  to  be 
achievable  (through  the  test  of  prototypes,  modeling  and  simulation,  etc.),  then  the  draft 
CDD  is  staffed  for  approval  before  Milestone  B.  If  the  requirements  were  found  to  be 
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not  achievable,  then  either  the  draft  CDD  is  refined  to  a  point  of  low  risk,  or  the  program 
may  be  terminated  or  re- scoped. 

Within  the  CDDs  and  CPDs  that  eventually  define  the  operational  requirements  of  a 
system  respectively  at  Milestones  B  and  C,  the  trade  space  is  established  through  the  use 
of  Key  Performance  Parameters  (KPPs).  Each  CDD  and  CPD  will  list  somewhere 
between  two  and  six  KPPs,  representing  the  most  critically  important  operational 
requirements  for  the  system.  Each  KPP  will  also  be  defined  in  terms  of  “threshold”  and 
“objective”  goals,  to  establish  a  trade  space  within  which  one  parameter  may  be  adjusted 
to  enable  the  achievement  of  another.  Some  common  types  of  KPPs  are  “net-centricity”, 
“force  protection”,  “survivability”,  “energy  efficiency”,  “mobility”,  and  “lethality”.  The 
threshold  and  objective  values  for  each  are  usually  described  in  one  to  two  sentences. 
The  system  performance  requirements  that  describe  how  to  achieve  each  operational 
requirement  for  each  will  be  developed  by  the  acquisition  and  engineering  communities 
as  part  of  a  performance  specification.  The  CDDs  and  CPDs  also  use  a  tiered 
prioritization  system  to  define  which  operational  requirements  are  more  important  than 
others.  This  enables  the  acquisition  and  engineering  community  to  achieve  a  better 
understanding  of  their  customers’  priorities  to  understand  any  trade-offs  that  must  be 
made  throughout  the  program. 

There  are  some  notable  differences  between  the  requirements  development  processes  of 
the  military  compared  to  the  commercial  sector.  In  the  Army,  there  is  an  organization 
known  as  the  Training  and  Doctrine  Command  (TRADOC).  One  of  the  core 
responsibilities  of  this  organization  is  to  generate  validated  operational  requirements 
(through  the  JCIDS  process  described  earlier).  This  organization  essentially  speaks  as 
the  “voice  of  the  customer”  to  the  acquisition  and  engineering  communities.  This  is 
different  from  the  profit-motivated  commercial  industry  where  there  is  no  single 
organization  representing  the  official  voice  of  the  customer.  In  most  private  industry 
product  development  processes,  companies  must  find  disciplined  and  innovative  ways  to 
understand  their  current  and/or  potential  customers,  target  market  segments,  and  more. 
This  includes  the  use  of  consumer  surveys,  market  analysis  studies,  “camping  out”  with 
the  customer,  and  even  using  anthropologists  and  psychologists  in  many  cases.  Of 
course,  the  military’s  more  controlled  process  of  requirements  development  is  not 
perfect.  The  fact  that  the  end  users  of  military  ground  systems  are  often  thousands  of 
miles  away  in  restricted  access  facilities  and  often  in  dangerous  scenarios  implies  that 
the  engineers  who  are  developing  new  systems  or  technology,  often,  have  much  less 
opportunity  to  interact  with  their  end  users  and  see  their  products  in  real-world  use.  This 
also  means  that  it  is  more  difficult  for  engineers  to  subject  their  systems  to  “use-case 
scenarios”  during  the  product  development  process  if  the  requirements  are  not  explicitly 
stated.  Also,  the  fact  that  an  organization  specifically  exists  to  speak  as  the  “voice  of  the 
customer”  may  in  some  cases  lead  to  the  engineers  on  the  product  development  side  to 
assume  that  all  requirements  have  already  explicitly  been  defined.  This,  in  turn,  may 
limit  their  motivation  to  reach  out  and  understand  the  end  users.  As  an  example,  in  a  war 
scenario,  equipment  may  be  subjected  to  abuse,  which  is  not  explicitly  defined. 
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Requirements  Management  &  Architecture 


Regarding  the  requirements  management  processes  that  are  employed  in  the  military 
ground  systems  domain,  a  variety  of  different  tools  are  used  for  different  programs. 
There  are  many  low-risk  programs  that  leverage  COTS  systems  in  the  commercial 
market  place.  These  low-risk  programs  tend  to  focus  more  on  simple  requirements 
management  tools.  For  the  low-risk  programs,  a  performance  specification  is  developed 
based  on  a  CDD  or  CPD.  This  performance  specification  is  usually  developed  by  an  IPT 
consisting  of  acquisition  leaders,  engineers,  logisticians,  test  specialists,  environmental 
specialists,  and  safety  specialists.  The  performance  specification  takes  the  operational 
requirements  as  defined  in  the  CDD  or  CPD  and  decomposes  them  to  the  next  level  of 
detail,  to  include  specific  power,  weight,  overall  dimensional  envelope,  and  legal  and 
regulatory  requirements  such  as  environmental,  safety,  and  electromagnetic  spectrum 
allocation  information  for  systems  that  require  advanced  communication  systems.  These 
performance  specifications  are  controlled  by  the  DoD  and  are  usually  captured  in  simple 
documents  or  spreadsheets.  In  many  cases,  disciplined  traceability,  between 
requirements,  are  not  maintained  due  to  the  low  risk,  non-complex  nature  of  the  COTS 
programs.  On  award  of  a  contract,  a  detailed  product  level  specification  is  provided  and 
controlled  by  the  contractor. 

An  example  of  a  COTS  equipment  meeting  the  Army’s  requirements  with  minor 
modifications  is  the  Line  of  Communication  Bridge  (LOCB).  For  civilian  applications, 
the  above  bridges  have  been  used  world-wide  in  situations  of  natural  calamities.  Figure 
4  shows  the  use  of  a  US  company  manufactured  LOCB  at  ground  zero  after  the  9/11 
attack  on  the  twin  towers  in  New  York.  Figure  5(a)  shows  the  application  of  LOCB 
from  a  UK  manufacturer  carrying  interstate  traffic  in  Baltimore  County,  Maryland. 
Figure  5(b)  shows  the  UK  company  manufactured  LOCB  in  use  by  the  military  in  Iraq. 
In  this  case,  from  systems  engineering  perspective,  the  acquisition  process  for  the  Army 
directly  proceeded  from  the  ICD  to  the  CPD,  eliminating  the  need  for  a  CDD. 

Hence,  acquiring  a  COTS  technology  solution  for  a  military  application  results  in  a 
reduced  acquisition  and  fielding  period  with  low  risk. 
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Figure  4:  A  US  Company  Manufactured  COTS  LOCB  at  Ground  Zero  after  the 

9/11  Calamity  (2) 


Figure  5(a)  A  UK  Company  Figure  5(b)  A  UK  Company 

Manufactured  COTS  LOCB  for  Manufactured  LOCB 
Interstate  Traffic  in  Maryland  (3)  in  Use  by  the  Army  at  Iraq  (3) 

For  more  complex  system  development  efforts,  a  variety  of  more  disciplined  tools  are 
utilized  to  maintain  the  consistency  and  integrity  between  the  different  levels  of 
requirements.  A  common  tool  for  larger  acquisition  programs  or  more  complex  R&D 
programs  is  to  use  a  relational  database,  to  create  and  maintain  traceability  between  the 
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operational  and  performance  requirements,  product  specifications,  and  test  methods. 
These  types  of  tools  help  organizations  keep  a  variety  of  requirements  up  to  date,  even 
when  modification  of  one  requirement  may  affect  many  other  requirements.  It  should  be 
noted  that  these  types  of  tools  may  demand  a  very  experienced  user  to  operate  the 
software  and  can  become  the  sole  responsibility  of  that  individual.  Hence,  programs  with 
very  little  budget  may  not  be  able  to  afford  the  investment  to  use  such  tools. 

For  the  decomposition  of  requirements  into  lower  levels,  some  widely  used  processes 
that  are  common  with  many  “lean”  or  “design  for  six  sigma”  related  methods  are  often 
used.  Often  a  concurrent  approach  to  decompose  operational  requirements  into  both  a 
functional  hierarchy  and  a  physical  hierarchy  is  utilized.  Figures  6  and  7  below  give 
examples  of  some  initial  de-compositions  from  the  DoD’s  Fuel  Efficient  Ground  Vehicle 
Demonstrator  (FED)  program  that  currently  is  being  executed  by  the  Army’s  Tank 
Automotive  Research,  Development  &  Engineering  Center  (TARDEC).  The  FED 
program  is  a  vehicle  system  level  demonstrator  program  that  is  intended  for  R&D  as 
opposed  to  immediate  fielding  in  the  military’s  inventory. 
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Figure  6:  Example  of  a  Preliminary  Draft  Functional  Decomposition  from  the 

FED  R&D  Program 
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Figure  7 :  Example  of  Draft  Physical  Decomposition  from  the  FED  R&D  program 


The  intention  to  simultaneously  produce  both  functional  and  physical  decompositions  is 
to  map  the  functions  to  physical  hierarchies  to  support  planning  as  a  program  progresses 
through  its  development  phase.  The  idea  is  that  as  a  system’s  architecture  progressively 
evolves  from  a  foggy  set  of  requirements  to  a  concept,  a  design,  and  finally  a  product. 
Decompositions  help  to  manage  requirements,  specifications  and  interfaces.  As 
decisions  are  periodically  made  on  the  various  sub-systems  of  the  system,  the  hierarchies 
are  updated  and  expanded  upon. 
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Another  commonly  used  tool  to  develop  and  manage  requirements  and  system 
architecture  is  the  DoD  Architecture  Framework  (DoDAF).  DoDAF  is  a  framework  that 
is  extensively  used  to  develop  net-centric,  remote  communications,  or  information 
technology  intensive  equipment.  Based  on  the  concept  of  “enterprise  architecture”,  the 
DoDAF  is  intended  to  define  a  set  of  documents  that  act  as  communication  tools  to 
visualize,  understand,  and  assimilate  the  complexities  of  an  architecture  description 
through  graphic,  tabular,  or  textual  means.  Use  of  the  DoDAF  forces  discipline  into  the 
architecture  development  process  by  requiring  the  creation  of  Operational  Views  (OVs), 
System  Views  (SVs),  and  Technical  Views  (TVs)  of  a  system  during  the  requirements 
development  and  decomposition  phases.  OVs  define  how  a  system  will  operate  on  a 
macro  scale,  including  what  it  must  communicate  with  or  interface  with,  and  who  will  be 
using  it  (which  military  services  or  which  nations).  The  SVs  are  used  to  define  and 
document  how  the  major  components  of  the  system  will  interface  with  the  different  users 
or  devices  (for  example,  which  components  of  a  system  will  use  satellite 
communications  and  which  will  use  radio  communications),  as  well  as  how  the  major 
components  within  a  system  will  interface  with  each  other.  TVs  are  used  to  define 
specific  open-systems  standards  to  ensure  interoperability  with  other  systems  and  to 
leverage  commercial  standards  (for  example,  which  internet  protocol?).  A  list  of 
approved  standards  is  maintained  by  the  DoD  and  the  TVs  must  ensure  that  they  comply 
with  the  list  to  maximize  interoperability  in  the  future.  Some  example  formats  for 
DoDAF  integrated  architectures  are  presented  in  Figure  8. 


Integrated  Architecture 

V  An  architecture  where  architecture  data 
elements  are  uniquely  identified  and 
consistently  used  across  all  products  and 
views  within  the  architecture. 


Figure  8:  Illustration  of  DoDAF  Integrated  Architecture  Products  (4) 
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Configuration  Management 


Configuration  management  is  the  process  to  maintain  a  consistent  and  an  up  to  date  set  of 
definitions  of  what  a  system  is  as  it  evolves  and  is  sustained  throughout  its  lifecycle. 
There  are  a  variety  of  levels  of  configurations,  at  various  requirements  levels,  to  meet  the 
actual  physical  and/or  software  configurations  of  a  system.  In  many  ways,  the  set  of 
operational  requirements,  which  are  developed  through  the  JCIDS  process  into  an  ICD, 
CDD,  or  CPD,  defines  the  highest  level  of  a  system’s  configuration.  Performance 
requirements  are  developed  based  on  the  operational  requirements.  These  performance 
requirements  represent  a  more  defined  level  of  a  system’s  configuration  or  architecture. 
As  detailed  product  level  requirements  or  descriptions  are  evolved,  they  represent  a  more 
detailed  system  configuration.  A  bill  of  materials  is  an  example  of  a  level  of 
configuration  that  must  be  maintained.  Another  example  is  a  set  of  drawings  or  a 
Technical  Data  Package  (TDP).  The  ultimate  level  of  a  system  configuration  is  the 
physical  makeup  of  an  actual  piece  of  hardware.  Configuration  management  shares  many 
processes  with  requirements  management,  as  it  aims  to  ensure  consistency  among  all 
different  levels  of  configurations.  All  quantities  of  a  given  component  within  the  product 
variants  should  be  the  same  throughout  their  fleet  and  the  drawings,  models  and 
requirements  defining  that  the  product  should  be  accurate  and  up  to  date,  even  after  a 
change  is  made  in  a  fleet  after  decades  of  being  fielded. 

The  terms  configuration  baseline  or  technical  baselines  refer  to  “locked”  configuration 
levels.  For  example,  an  approved  set  of  operational  requirements,  such  as  a  CDD,  would 
constitute  a  locked  “operational  baseline”.  The  approval  of  a  set  of  performance 
specifications  would  constitute  a  “functional  baseline”  being  established.  The 
performance  specifications  for  the  lower  level  configuration  items  within  a  system  would 
constitute  an  “allocated  baseline”.  The  detailed  drawings,  models,  and  bills  of  materials 
defining  the  exact  physical  attributes  of  a  system  would  constitute  a  “product  baseline”. 
Technical  baselines  are  established  or  “locked”  at  key  points  during  a  program.  For 
example,  “technical  reviews”  such  as  a  Preliminary  Design  Review  (PDR)  or  Critical 
Design  Review  (CDR)  are  respectively  used  to  establish  the  allocated  and  product 
baselines. 

A  very  useful  tool  used  for  the  technical  planning  of  a  program  is  a  specification  tree.  A 
specification  tree  essentially  is  a  communication  tool  to  convey  a  large  amount  of 
information  related  to  a  program’s  planned  configuration  management  approach.  In 
Figure  9,  an  example  specification  tree  is  shown  from  TARDEC’s  FED  program.  In  this 
specification  tree,  the  top  area  graphically  depicts  the  operational  baseline,  and  clarifies 
that  since  it  is  an  R&D  program  (as  opposed  to  a  Program  of  Record  to  be  fielded),  the 
operational  requirements  for  the  FED  program  were  defined  based  on  a  combination  of 
the  High  Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV)  Operational  Requirements 
Document  (ORD)  and  the  Joint  Light  Tactical  Vehicle  (JLTV)  Draft  CDD.  CPD  is  the 
revised  term  for  ORD.  The  arrow  on  the  left  of  the  graphic  indicates  that  the  FED 
operational  requirements  will  be  developed  during  the  concept  phase  of  the  program.  The 
blue  bubble  on  the  right  indicates  that  the  FED  operational  baseline  will  be  locked  during 
an  event  called  the  Executive  Steering  Group  Review.  The  next  level  down  shows  that  a 
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FED  system  specification  will  be  developed  to  define  the  functional  baseline  at  the 
beginning  of  the  development  phase.  The  functional  baseline  will  be  established  on 
conducting  a  PDR.  The  arrow  on  the  right  also  indicates  that  the  DoD  will  control  the 
operational  and  functional  baselines,  but  that  the  contractor  will  be  given  the  latitude  to 
control  the  more  detailed  technical  baselines  to  be  established  after  the  PDR.  Similar 
logic  is  used  to  define  both  how  and  when  the  allocated  and  product  level  baselines  will 
be  established  during  the  program. 
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Figure  9:  Example  of  a  Specification  Tree  from  the  FED  Program 


An  example  of  a  common  tool  used  to  bring  structure  and  discipline  to  a  configuration 
management  process  is  an  integrated  data  environment.  This  is  usually  a  secure  database 
where  program  team  members  can  “check  out”  and  “check  in”  documents  to  ensure  that  a 
single  version  of  a  document  or  drawing  is  being  worked  on  and  is  kept  up  to  date.  Often 
there  is  some  kind  of  workflow  and  approval  process  to  manage  changes  to  technical 
baselines  to  ensure  that  changes  to  one  baseline  maintains  consistency  with  other 
technical  baseline  levels  or  related  program  documentation.  Numbering  conventions  for 
version  control  are  often  utilized  to  communicate  to  team  members  what  level  of 
approval  a  given  version  of  a  document  has  been  subjected  to. 
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Technical  Reviews 


Technical  reviews  are  events  conducted  during  a  program’s  lifecycle  to  address  risk 
mitigation,  establish  configuration  baselines,  and  maximize  a  program’s  overall 
probability  of  success.  Common  technical  reviews  used  during  the  design  phase  of  a 
program  are  the  PDR  and  CDR.  Contrary  to  the  way  that  many  programs  are  planned, 
technical  reviews  are  intended  to  be  “event-driven”  as  opposed  to  “calendar  driven”.  The 
basic  concept  is  that  the  program’s  leadership  must  define  the  activities  and  artifacts  to  be 
completed  prior  to  each  technical  review  (entrance  criteria).  Then  the  technical  reviews 
are  conducted  after  each  of  the  entrance  criteria  activities  are  completed.  This  essentially 
serves  as  a  way  to  ensure  that  a  program  does  not  progress  into  the  next  phase  till  its 
overall  risk  is  reduced  to  a  defined  level,  making  it  manageable.  On  completion  of  each 
technical  review,  a  set  of  “exit  criteria”  is  implemented.  An  example  is  the  locking  in  of 
an  established  product  baseline.  The  technical  reviews  are  not  intended  to  be  forums  for 
heated  discussions.  They  are  intended  to  review  and  validate  that  a  program  is  mature  and 
healthy  enough  to  progress  into  the  next  planned  phase. 

Risk  Management 

Risk  management  is  a  common  practice  used  by  many  industries  to  increase  the 
probability  of  success  of  a  given  event  or  outcome.  Although  risk  management  fits  within 
the  overall  direct  responsibility  of  program  management;  it  is  also  commonly  associated 
with  systems  engineering.  The  DoD’s  approach  to  risk  management  is  not  unique. 

Similar  to  the  approaches  adopted  in  the  commercial  industry,  risks  are  identified  and 
characterized  based  on  an  assumed  probability  of  occurrence  and  severity  of  the  potential 
consequence.  Risks  are  prioritized  into  high  risk,  medium  risk,  and  low  risk,  or  some 
other  prioritization  system.  Figure  10  shows  a  typical  “risk  matrix”  that  is  used  to 
communicate  the  severity  of  risks.  Once  risks  are  identified  and  characterized  in  terms  of 
severity,  a  path  forward  is  defined  to  handle  the  same.  In  the  DoD,  typical  choices  to 
handle  a  given  risk  are  to  avoid  the  risk,  control  the  risk,  transfer  the  risk,  or  accept  the 
risk.  In  some  cases,  a  90%  solution  to  a  problem  that  can  be  implemented  in  a  matter  of 
weeks  is  preferred  over  a  100%  solution  that  would  take  many  months  to  implement. 


Probability 

Figure  10:  Risk  Matrix 
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Details  of  risk  management  are  well  understood  by  different  industries,  and  therefore  will 
not  be  discussed  in  this  chapter.  However,  the  key  to  effective  risk  management  is  to 
determine  as  to  how  to  integrate  it  into  a  given  program’s  “battle  rhythm”.  Differently 
stated,  each  project  team  should  establish  some  regular,  recurring  process  to  identify  new 
risks,  track  existing  risks,  characterize  risks,  develop  action  plans  to  execute  risk 
mitigation  strategies,  and  assign  ownership  for  executing  the  action  plans. 

Technology  Maturity 

Managing  the  maturity  of  technology  is  an  important  practice  in  the  military.  The  fact 
that  the  military  often  requires  capabilities  that  are  unique  from  commercial  capabilities 
implies  that  emerging  technologies  often  become  important.  Additionally,  the  military’s 
objective  of  maintaining  a  strategic  advantage  over  its  adversaries  implies  that  the  use  of 
new  commercial  technologies  can  be  leveraged  to  create  a  strategic  disadvantage  for 
adversarial  countries  or  organizations. 

The  most  common  tools  used  to  manage  technological  maturity  are  Technology 
Readiness  Levels  (TRLs).  The  TRLs,  used  by  the  DoD,  are  based  on  definitions  by  the 
National  Aeronautics  and  Space  Administration  (NASA).  A  summary  of  the  TRLs  used 
by  the  DoD  is  included  in  Table  1. 

There  is  often  a  debate  and  discussion  regarding  what  constitutes  one  TRL  level  versus 
another.  The  TRL  levels  often  become  a  very  useful  tool  to  plan  a  program,  manage  risk, 
and  determine  the  cost  and  schedule  trade-offs  between  potential  future  systems  that 
would  utilize  different  levels  of  technological  maturity.  Figure  1 1  shows  a  common 
planning  methodology  for  what  levels  of  TRLs  are  appropriate  for  which  stages  in  a 
program’s  lifecycle.  The  most  critical  element  to  discern  from  Figure  11  is  that 
technologies  of  TRL  6  or  higher  must  be  attained  by  Milestone  B. 

Since  the  function  of  maturing  technology  is  handled  by  a  one  DoD  organization  (the 
R&D  centers  such  as  TARDEC)  while  the  function  of  developing  and  fielding  full 
systems  is  handled  by  the  Program  Managers  (PMs),  it  is  important  that  the  organizations 
maintain  coordination  as  to  their  plans  and  progress  with  reference  to  the  program.  A 
commonly  used  tool  to  facilitate  this  is  a  Technology  Transition  Agreement  (TTA).  A 
TTA  is  a  document  that  is  signed  by  officials  from  both  the  R&D  and  the  PM 
organizations  (and  any  other  relevant  stakeholders)  who  define  the  criteria  by  which  the 
PM  will  decide  on  whether  to  utilize  the  technology.  Typically  the  R&D  organizations 
prepare  the  TTA  and  obtain  written  statements  from  the  PM  defining  whether  they  show 
“interest”,  “intent”  or  “commitment”  to  use  the  technology. 
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TRL 

Definition 

Description 

Supporting  Information 

1 

Basic  principles 
observed  and 
reported. 

Lowest  level  of  technology 
readiness.  Scientific 
research  begins  to  be 
translated  into  applied 
research  and  development 
(R&D).  Examples  might 
include  paper  studies  of  a 
technology's  basic 
properties. 

Published  research  that  identifies  the 
principles  that  underlie  this  technology. 
References  to  who,  where,  when. 

2 

Technology  con¬ 
cept  and/or  appli¬ 
cation  formulated. 

Invention  begins.  Once 
basic  principles  are 
observed,  practical  applica¬ 
tions  can  be  invented.  Appli¬ 
cations  are  speculative,  and 
there  may  be  no  proof  or 
detailed  analysis  to  support 
the  assumptions.  Examples 
are  limited  to  analytic 
studies. 

Publications  or  other  references  that  out¬ 
line  the  application  being  considered  and 
that  provide  analysis  to  support  the 
concept 

3 

Analytical  and 
experimental  criti¬ 
cal  function  and/or 
characteristic  proof 
of  concept 

Active  R&D  is  initiated.  This 
includes  analytical  studies 
and  laboratory  studies  to 
physically  validate  the 
analytical  predictions  of 
separate  elements  of  the 
technology.  Examples 
include  components  that  are 
not  yet  integrated  or 
representative. 

Results  of  laboratory  tests  performed  to 
measure  parameters  of  interest  and  com¬ 
parison  to  analytical  predictions  for  critical 
subsystems.  References  to  who.  where, 
and  when  these  tests  and  comparisons 
were  performed. 

4 

Component  and/or 
breadboard  valida¬ 
tion  in  a  laboratory 
environment 

Basic  technological  compo¬ 
nents  are  integrated  to 
establish  that  they  will  work 
together  This  is  relatively 
low  fidelity*  compared  with 
the  eventual  system.  Exam¬ 
ples  include  integration  of 
“ad  hoc’  hardware  in  the 
laboratory. 

System  concepts  that  have  been  consi¬ 
dered  and  results  from  testing  laboratory- 
scale  bread boardisL  References  to  who 
did  this  work  and  when.  Provide  an  esti¬ 
mate  of  how  breadboard  hardware  and 
test  results  differ  from  the  expected  sys¬ 
tem  goals. 

5 

Component  and/or 
breadboard  valida¬ 
tion  in  a  relevant 
environment. 

Fidelity  of  breadboard 
technology  increases 
significantly  The  basic 
technological  components 
are  integrated  with  reason¬ 
ably  realistic  supporting 
elements  so  they  can  be 
tested  in  a  simulated  envi¬ 
ronment  Examples  include 
'‘high-fidelity”  laboratory 
integration  of  components. 

Results  from  testing  a  laboratory  bread¬ 
board  system  are  integrated  with  other 
supporting  elements  in  a  simulated  oper¬ 
ational  environment.  How  does  the  “rele¬ 
vant  environment"  differ  from  the 
expected  operational  environment?  How 
do  the  test  results  compare  with  expecta¬ 
tions?  What  problems,  if  any  were 
encountered?  Was  the  breadboard  sys¬ 
tem  refined  to  more  nearly  match  the 
expected  system  goals? 
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TRL 

Definition 

Description 

Supporting  Information 

6 

SystenYsubsystem 
model  or  prototype 
demonstration  in  a 
relevant 
environment 

Representative  model  or 
prototype  system,  which  is 
well  beyond  that  of  TRL  5,  is 
tested  in  a  relevant  environ¬ 
ment.  Represents  a  major 
step  up  in  a  technology  s 
demonstrated  readiness. 
Examples  include  testing  a 
prototype  in  a  high-fidelity 
laboratory  environment  or  in 
a  simulated  operational 
environment. 

Results  from  laboratory  testing  of  a  proto¬ 
type  system  that  is  near  the  desired  con¬ 
figuration  in  terms  of  performance,  weight, 
and  volume.  How  did  the  test  environment 
differ  from  the  operational  environment? 
Who  performed  the  tests?  How  did  the 
test  compare  with  expectations?  What 
problems  if  any  were  encountered? 

What  are/were  the  plans,  options,  or 
actions  to  resolve  problems  before 
moving  to  the  next  level? 

7 

System  prototype 
demonstration  in 
an  operational 
environment 

Prototype  near  or  at  planned 
operational  system.  Repre¬ 
sents  a  major  step  up  from 
TRL  6  by  requiring  demon¬ 
stration  of  an  actual  system 
prototype  in  an  operational 
environment  (e  g.,  in  an  air¬ 
craft,  in  a  vehicle,  or  in 
space). 

Results  from  testing  a  prototype  system  in 
an  operational  environment.  Who  per¬ 
formed  the  tests?  How  did  the  test  com¬ 
pare  with  expectations?  What  problems, 
if  any.  were  encountered?  What  are/were 
the  plans,  options,  or  actions  to  resolve 
problems  before  moving  to  the  next  level? 

8 

Actual  system 
completed  and 
qualified  through 
test  and 
demonstration 

Technology  has  been 
proven  to  work  in  its  final 
form  and  under  expected 
conditions.  In  almost  all 
cases,  this  TRL  represents 
the  end  of  true  system 
development.  Examples 
include  developmental  test 
and  evaluation  (DT&E)  of 
the  system  in  its  intended 
weapon  system  to  deter¬ 
mine  if  it  meets  design 
specifications. 

Results  of  testing  the  system  in  its  final 
configuration  under  the  expected  range  of 
environmental  conditions  in  which  it  will 
be  expected  to  operate.  Assessment  of 
whether  it  will  meet  its  operational 
requirements.  What  problems,  if  any, 
were  encountered’  What  are/were  the 
plans,  options,  or  actions  to  resolve 
problems  before  finalizing  the  design? 

9 

Actual  system 
proven  through 
successful  mission 
operations. 

Actual  application  of  the 
technology  in  its  final  form 
and  under  mission  condi¬ 
tions,  such  as  those 
encountered  in  operational 
test  and  evaluation  (OT&E). 
Examples  include  using  the 
system  under  operational 
mission  conditions. 

OT&E  reports. 

Table  1:  TRL  Definitions 
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Figure  11:  Alignment  of  TRLs  with  Acquisition  Lifecycle 
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Systems  Engineering  Metrics 


Systems  engineering  metrics  are  used  in  the  DoD  for  tracking  progress  toward  an 
objective  and  for  establishing  success  criteria.  Metrics  may  be  defined  for  a  specific 
program,  or  for  an  entire  organization. 

For  program  specific  metrics,  a  common  practice  is  to  use  Technical  Performance 
Measures  (TPMs).  TPMs  are  technical  metrics  that  are  established  based  on  KPPs  and/or 
the  technical  requirements  that  correlate  to  the  most  significant  program  risks.  Table  2 
displays  an  example  of  TPMs  for  a  program.  The  idea  is  that  the  responsible  IPTs  will 
track  progress  toward  meeting  each  of  the  requirements.  Feedback  based  on  tracking  the 
TPMs  will  influence  the  program’s  risk  management  activities. 


KPP 

TPMs 

Responsible  IPT 

Conflict  /  Justification 

Mobility 

Top  Speed 

Mobility  Sub-IPT 

Potentially  conflicts  with  Payload 
KPP 

Mobilty 

Speed  on  Grade 

Mobility  Sub-IPT 

Potentially  conflicts  with  Payload 
KPP  (CH-47  internal  transport) 

Transportability 

Weight 

Transportability  Sub-IPT 

Potentially  conflicts  with  Force 
Protection  KPP 

Transportability 

Site 

Transportability  Sub-IPT 

Multiple  Envelopes 

Net  Ready 

Confuting  Resource  Metric 

Software  Metric.  Power 

C4ISR  IPT 

Complex  integration 

Force  Protection 

Armor  pounds  per  square  foot  to 
meet  required  protection  levels; 

Armor  trls 

Survivabilty  Sub-IPT 

Reqiirements  net  demonstrated 
in  relevant  environment 

Survivability 

Weight  Supported  by  Roof 

ESOH  IPT 

Safety  is  paramount 

Payload 

Weight  Capacity  volume  Capacty 

Mobility  Sub-IPT 

Potentially  conflicts  with  Mobflity 
KPP 

Material  Availability 

Reliability 

Reliability  sub-iPT 

Reliability  requirements  never 
demonstrated  on  similar 
systems 

Integratec  Performance 

Rollup  of  all  other  TPMs;  System 
Integration  Metric 

SE  IPT 

Integrated  performance  never 
demonstrated  on  similar 
systems 

Table  2:  Example  of  TPMs  for  a  Program 


Conclusion 


There  are  a  variety  of  common  systems  engineering  practices  within  the  DoD.  Through 
the  disciplined  application  of  these  tools,  better  products  are  delivered  to  customers  faster 
and  at  reduced  cost.  The  majority  of  these  tools  are  readily  applicable  to  products  outside 
of  the  realm  of  the  defense  industry. 
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Disclaimer 

Reference  herein  to  any  specific  commercial  company,  product,  process  or  service  by 
trade  name,  trademark,  manufacturer,  or  otherwise,  does  not  necessarily  constitute  or 
imply  its  endorsement,  recommendation,  or  favoring  by  the  United  States  Government  of 
the  Department  of  the  Army  (DoA).  The  opinions  of  the  authors  expressed  herein  do  not 
necessarily  state  or  reflect  those  of  the  United  States  Government  of  the  DoA,  and  shall 
not  be  used  for  advertising  or  product  endorsement  purposes. 
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